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Abstract 


Level design plays a key role in the development of a video game, since it 
allows to transform the game design in the actual gameplay that the final 
user is going to experience. Nevertheless, we are still far from a scientific 
approach to the subject, with a complete lack of a shared terminology and 
almost no experimental validation for the most used techniques. Even if the 
video game industry does not acknowledge this problem, in the last years 
the academic environments have shown an increasing interest towards this 
subject. 

We analyzed the main breakthroughs made in level design research applied 
to the genre of First Person Shooters, devoting particular attention to the 
ones that try to assist the design process by employing Procedural C'ontent 
Generation. To support this kind of research, we developed an open-source 
framework that employs procedural algorithms to generate maps with dif- 
ferent topologies, both single-level and multi-level, but that also allows to 
import maps generated in previous works, thanks to a broad support to the 
most common export formats used in the literature. The framework was also 
designed for providing an easy way to define and deploy browser-playable 
online experiments, that allow to analyze how real users react to different 
contents. 

We also explored a novel approach for the analysis of First Person Shooter 
levels, that uses Graph Theory to extract information about the layout of a 
map. We used this information to define an approach that uses heuristics to 
place game elements considering the layout of the map and the features of 
each element. 


Sintesi 


Il level design gioca un ruolo chiave nello sviluppo di un videogioco, dal mo- 
mento che permette di trasformare il game design nell’effettiva esperienza di 
gameplay che verrà sperimentata dall’utente finale. Nonostante ciò, siamo 
ancora lontani da un approccio scientifico verso la materia, a causa della 
completa mancanza di un vocabolario condiviso e della quasi totale assenza 
di validazione sperimentale per le tecniche più comuni. Anche se l’industria 
tende ad ignorare questo problema, negli ultimi anni gli ambienti accademici 
hanno mostrato un crescente interesse verso questo campo. 

Abbiamo analizzato le principali scoperte fatte nel campo del level design ap- 
plicato al genere dei First Person Shooter, riservando particolare attenzione 
ai casi in cui si usa la Generazione Procedurali di Contenuti per assistere il 
processo di design. Per agevolare questo tipo di ricerca, abbiamo sviluppato 
un framework open-source che si avvale di algoritmi procedurali per generare 
mappe con topologie differenti, con uno o più piani, ma che permette anche 
di importare le mappe generate nei lavori precedenti, grazie ad un vasto sup- 
porto per i formati di esportazione più diffusi in questo campo. Il framework 
è stato anche progettato per consentire la facile creazione di esperimenti on- 
line giocabili da browser, che permettono di analizzare come degli utenti reali 
reagiscono a differenti tipi di contenuto. 

Abbiamo anche esplorato un nuovo approccio per l’analisi dei livelli per First 
Person Shooter, che si avvale della Teoria dei Grafi per estrarre informazioni 
riguardanti il layout di una mappa. Utilizzando queste informazioni, abbi- 
amo definito un approccio basato su euristiche per disporre gli elementi di 
gioco tenendo conto del layout della mappa e delle caratteristiche di ciascun 
elemento. 
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Chapter 1 


Introduction 


Video games are really complex products, but it is rather simple to point 
out three elements that mainly influence their commercial success: visuals, 
gameplay! and narrative. If in the past visual improvements were impres- 
sively fast, with games looking more and more realistic from year to year, 
lately this progress consistently slowed down, leaving narrative and game- 
play as the main selling points. Since video games are interactive products, 
the latter is the one that influences user experience the most. Gameplay is 
defined by a set of rules commonly referred as game design. To the player, 
game design is presented in a tangible way via level design, which consists 
in the creation of the worlds where the game takes place. This is a critical 
component, since an inadequate level design can easily compromise the whole 
experience. 

One of the most successful video game genre is the one of First Person 
Shooters, that thanks to its first player perspective allows the user to exper- 
iment a complete immersion in the game world. From the very beginning, 
this has required a close attention to level design, that underwent a constant 
evolution, up to the stable situation of the recent years. Furthermore, the 
ever-increasing success of competitive multiplayer added a new level of com- 
plexity to the creation of maps, that need to support different game modes, 
play styles and interactions, allowing a fun and challenging gameplay to arise 
naturally. 


1.1 Motivations and purpose 


Despite the importance of level design for the FPS genre, the video game in- 
dustry has never attempted a scientific approach to this field. Consequently, 


1The specific way in which players interact with the game. 
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game design is a rather abstract discipline, with no common vocabulary or 
well-defined standards, but rather based on the experience of who is working 
in this field from many years. This affects also the related literature, that is 
confined to listing the most used patterns and conventions, without focusing 
on why they work. 

In the last years, instead, academic environments started to address this 
discipline with increasing interest. The researches performed in this field 
revolve around the identification and definition of design patterns and design 
techniques, with a deep analysis of how and why they work, and the creation 
of novel approaches to level design. Some of these techniques try to automate 
the design process by employing procedural generation, often combined with 
evolutionary algorithms. 

A problem peculiar to this kind of research is how difficult it is to obtain 
information from real users, since this requires them to either download a 
specific game or to take part in play-test sessions and both option discourage 
participation. 

The aim of this thesis is to solve this problem and to attempt a novel 
approach to map analysis and game element placement. The former was 
addressed by designing an open-source framework capable of generating and 
importing single-level and multi-level maps and of deploying online experi- 
ments to collect data from real users via a browser-playable FPS game. The 
latter, instead, was achieved by using Graph Theory to compute topological 
metrics from multiple graph representation of the maps, each one highlight- 
ing different features, and by using the information provided by these metrics 
to strategically place game elements, paying attention to the gameplay dy- 
namics associated with each one of them. 


1.2 Synopsis 
The contents of the thesis are the followings: 


In the second chapter we describe the state of the art of First Person 
Shooters, both in academic research and in commercial games, paying at- 
tention on how level design practices and procedural content generation are 
applied in this genre. We also list some examples of how Graph Theory is 
employed in video games. 


In the third chapter we present the framework that we have developed, 
analyzing its features and its overall structure. 


1.2. Synopsis 


In the fourth chapter we present an approach that uses Graph Theory 
to place game elements in procedurally generated levels, with an overview of 
the theory and the assumptions behind it. 


In the fifth chapter we describe an experiment performed with our frame- 
work for validating the heuristics that we have defined for the placement of 
spawn points. 


In the concluding chapter we evaluate the obtained results and we analyze 
the potential future developments of this work. 


Chapter 2 


State of the art 


In this chapter we analyze the current state of Level Design and of its common 
practices, both in academic and in professional environments, with attention 
to the genre of First Person Shooters (or FPS). 

We then talk about Procedural Content Generation (or PCG), focusing 
on how it allows to enrich and ease the design process. 

After that, we give an overview of the First Person Shooter genre, ana- 
lyzing its features, history and evolution, devoting special attention to the 
games that mostly contributed to the definition of this genre. 

Finally, we analyze how Graph Theory has been in used in Video Games 
during the years. 


2.1 Level Design Theory 


Level Design is a game development discipline focused on the creation of 
video game levels. 

Today, the level designer is a well-defined and fundamental figure in the 
development of a game, but it was not always so. In the early days of the 
video game industry, it was a widespread practice to assign the development 
of levels to members of the team with other roles, usually programmers. 
Apart from the limited number of team members and the low budget, this 
was because there were no tools such as level editors', that allowed the level 
designer to work on a level without being involved with code. 

The level designer has a really significant role in the development of a 
good game, since he is responsible for the creation of the world and for how 
the player interacts with it. The level designer takes an idea and makes it 


1A level editor is a software used to design levels, maps and virtual worlds for a video 
game. 
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tangible. Despite the importance of this process, after all this years it has 
not been established a common ground or a set of standards and level design 
is still considered as a form of art, based on heuristics, observation, previous 
solutions and personal sensibility. 

In addition to gameplay, the game designer must consider the visual ap- 
pearance of the level and the technological limitations of the game engine?, 
combining all this elements in a harmonic way. 

One of the core components of level design is the “level flow”. For single 
player games it translates into the series of actions and movements that the 
player needs to perform to complete a level. A proficient level design practice 
is to guide the player in a transparent way, by directing his attention towards 
the path he needs to follow. This can be achieved in diverse ways. Power 
ups and items can be used as breadcrumbs to suggest the right direction in a 
one-way fashion, since they disappear once picked up. Lighting, illumination 
and distinctly colored objects are another common approach to this problem. 
A brilliant example of this is Mirror's Edge”, which uses a really clear color 
code, with red interactive objects in an otherwise white world, to guide the 
player through its fast-paced levels. There are also even more inventive 
solutions, like the dynamic flock of birds in Half Life 24, used to catch the 
player attention or to warn him of incoming dangers[3]. Finally, sounds and 
architectures are other elements that can be used to guide the player. In the 
academic environment, a lot of researchers have analyzed the effectiveness 
of this kind of solutions: Alotto[4] considers how architecture influences the 
decisions of the player, whereas Hoeg[5] also considers the effect of sounds, 
objects and illumination, with the last being the focus of Brownmiller's[6] 
work. 

In multiplayer games the level flow is defined by how the players interact 
with each other and with the environment. Because of this, the control of the 
level designer is less direct and is exercised almost exclusively by modeling 
the map. Considering FPS, the level flow changes depending on how much an 
area is attractive for a player. The more an area is easy to navigate or offers 
tactical advantage, such as covers, resources or high ground, the more players 
will be comfortable moving in it. This doesn't mean that all areas need to 
be designed like this, since zones with a “bad” flow but an attractive reward, 
such as a powerful weapon, force the player to evaluate risks and benefits, 
making the gameplay more engaging. The conformation of the map and the 
positioning of interesting resources are used to obtain what Güttler et al. [7] 


2A game engine is a software framework designed for the creation and development of 
video games. 

3Digital Illusions CE, 2008. 

“Valve, 2004. 
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define as “points of collisions”, i.e. zones of the map were the majority of 
the fights are bound to happen. 

Moving back to academic research, Güttler et al. have also noticed how 
aesthetic design loses importance in a multiplayer context. Other researches 
are instead focused on finding patterns in the design of multiplayer maps: 
Larsen[8] analyzes three really different multiplayer games, Unreal Tourna- 
ment 2004°, Day of Defeat: Source? and Battlefield 1942", identifying shared 
patterns and measuring their effect on gameplay, suggesting some guidelines 
on how to use them, whereas Hullet and Whitehead identify some patterns 
for single player games[9], many of whom are compatible with a multiplayer 
setting, with Hullett also proving cause-effect relationships for some of this 
patterns by confronting hypothesized results with the ones observed on a 
sample of real players[10]. Despite these experimental results contributing 
to a formalization of level design, we are still far from a structured scientific 
approach to the subject. 


2.2 Procedural Content Generation 


Procedural Content Generation refers to a family of algorithms used to cre- 
ate data and content in an automatic fashion. In game development it is 
commonly used to generate weapons, objects, maps and levels, but it is also 
employed for producing textures, models, animations, music and dialogues. 
The first popular game to use this technique was Rogue®, an ASCII dun- 
geon exploration game released in 1980, where the rooms, hallways, monsters, 
and treasures the player was going to find were generated in a pseudo-random 
fashion at each playthrough. Besides providing a huge replay value to a game, 
PCG allowed to overcome the strict memory limitations of the early comput- 
ers. Many games used pseudo-random generators with predefined seed values 
to create very large game worlds that appeared to be premade. For instance, 
the space exploration and trading game Elite? contained only eight galaxies, 
each one with 256 solar systems, of the possible 282 trillion the code was able 
to generate, since the publisher was afraid that such an high number could 
cause disbelief in the players. Another example is the open world action 
role-playing game The Elder Scrolls II: Daggerfall*”, which game world has 


5Epic Games, 2004. 

6Valve, 2005. 

"DICE, 2002. 

®Michael Toy, Glenn Wichman, 1980. 
David Braben, Ian Bell, 1984. 
lBethesda Softworks, 1996. 
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the same size of Great Britain. 

As computer hardware advanced and the size of the memory increased, 
procedural generation of game worlds was generally put aside, since it could 
not compete with the level of detail that hand-crafted worlds were able to 
achieve. 

However, in the last years, with the players’ expectations and the pro- 
duction value of video games constantly increasing, procedural generation 
made a comeback as a way to automate the development process and reduce 
costs. Many middleware tools, such as SpeedTree!! and World Machine”, are 
used to produce various kind of content, like terrain and natural or artificial 
environments. 

Many modern AAA!’ games use procedural generation: in Borderlands** 
a procedural algorithm is responsible for the generation of guns and other 
pieces of equipment, with over a million unique combinations; in Left 4 
Dead! an artificial intelligence is used to constantly make the players feel 
under threat, by dynamically changing the music, spawning waves of ene- 
mies and changing the accessible paths of the level; in Spore! procedural 
animation is employed to determine how the creatures created by the player 
move. 

Nowadays, PCG is widely used by independent developers, that, lacking 
the high budgets of AAA games, try to obtain engaging and unusual game- 
play using unconventional means. The most famous example is Minecraft!”, 
a sandbox survival game which worlds, composed exclusively by cubes, are 
generated automatically. Currently, the most extreme form of procedural 
generation is the one found in No Man's Sky*, a space exploration game 
where space stations, star-ships, planets, trees, resources, buildings, animals, 
weapons and even missions are generated procedurally. Following in the foot- 
step of their forefather, many roguelike games still use PCG, like The Binding 
of Isaac’. 

All the algorithms used by these games and middleware are designed to 
be as fast as possible, since they need to generate the content in real time. In 
the last years researchers have nevertheless tried to explore new paradigms, 


!IDV, Inc. 

2World Machine Software, LLC. 

3Video games produced and distributed by a major publisher, typically having high de- 
velopment and marketing budgets. 

4Gearbox Software, 2009. 

5Valve, 2008. 

6Maxis, 2008. 

"Mojang, 2011. 

SHello Games, 2016. 

“Edmund McMillen, 2011. 
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creating more complex procedural generation techniques, that allow for a 
tighter control on the output. Being one of the problems of PCG the lack 
of an assured minimum quality on the produced content, the academic en- 
vironment has focused not only on more advanced generation algorithms, 
but also on techniques to evaluate the output itself in an automatic fash- 
ion. In this field, Togelius et al.[11] defined Search-Based Procedural Content 
Generation, a particular kind of Generate-And- Test? algorithm, where the 
generated content, instead of being just accepted or discarded, is evaluated 
assigning a suitability score obtained from a fitness function, used to select 
the best candidates for the next iterations. 


2.3 Procedural Content Generation for FPS 
maps 


We have really few examples of commercial FPS that use PCG to generate 
their maps: with the exception of Soldier of Fortune II: Double Helix?!, that 
employs these techniques to generate whole missions, the few other cases we 
have are all roguelikes with a FPS gameplay, like STRAFE?. 

Despite the total lack of FPS using procedural generation to obtain mul- 
tiplayer maps, researchers have proved that search-based procedural content 
generation can be an useful tool in this field. In a seminal work, Cardamone 
et al.[12] tried to understand which kind of deathmatch? maps created the 
most enjoyable gameplay possible. To achieve this, the authors generated 
maps for Cube 2: Sauerbraten?* by maximizing a fitness function computed 
on fight time data collected from simulations’, with the fight time being the 
time between the start of a fight and the death of one of the two contenders. 
The choice of this fitness function is based on the consideration that a long 
fight is correlated with the presence of interesting features in the map, such 
as escape or flanking routes, hideouts and well positioned resources. 


20 Algorithms with both a generation and an evaluation component, that depending on 
some criterion, decide to keep the current result or to generate a new one. 

21Raven Software, 2002. 

22Pixel Titans, 2017. 

23A widely used multiplayer game mode where the goal of each player is to kill as many 
other players as possible until a certain end condition is reached, commonly being a kill 
limit or a time limit. 

24Wouter van Oortmerssen, 2004 

25In the field of search-based procedural generation, fitness function based on simulation 
are computed on the data collected from a match between artificial agents in the map 
at issue. They differ from direct and interactive functions, that evaluate, respectively, 
the generated content and the interaction with a real player. 
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Stucchi et al.[13], yet remaining in the same field, attempted a completely 
different use of procedural generation, by producing balanced maps for player 
with different weapons or different levels of skill. For doing so, they generated 
procedural maps via evolutionary algorithms, evaluating them with a fitness 
function based on simulation that computes the entropy of kills. Starting 
from a situation where one of the two players has a significant advantage, 
they proved that changes in the map structure allow to achieve a significant 
balance increase. 


Arnaboldi[14] combined these two approaches, creating a framework that 
automatically produces maps using a genetic process like the one of Car- 
damone. In Arnaboldi's work, however, the fitness function is way more 
complex, since it considers a high number of gameplay metrics, and the AI 
of the employed bots? is closer to the one of a human player, thanks to a 
series of adjustments made to the stock Cube 2 one. These improvements 
significantly increase the flexibility of the framework and the overall quality 
of the output, allowing to identify and analyze some recurring patterns and 
their relationship with the statistics gathered during the simulations. 

Ølsted et al.[1] moved the focus of their research from deathmacth to 
squad game modes with specific objectives, sustaining not only that the maps 
generated by Cardamone et al. are not suitable for this kind of gameplay, but 
also that they do not conform to what they define as The Good Engagement 
(or TGE) rules, i.e. a set of rules that a FPS should satisfy to support 
and encourage interesting player choices, from which an engaging gameplay 
should emerge naturally. By analyzing the Search & Destroy?” mode of games 
like Counter Strike? and Call of Duty?®, they defined a process to generate 
suitable maps: starting from a grid, some nodes are selected and connected 
among them, the result is then optimized to satisfy the TGE rules and finally 
rooms, resources, objects and spawn points are added, as can be seen in figure 
2.1. Opting for an interactive approach, the fitness function used to guide 
the evolution of these maps is computed on the binary appreciation feedback 
expressed by real users, since the authors consider bot behavior too different 
form the one of real users. 

A completely different approach from the ones listed above is the one of 
Anand and Wong[15], who employed search-based procedural generation to 
create online, automatically and rapidly multiplayer maps for the Capture 


26The artificial players of a video game. 

27A multiplayer game mode where players, divided in two teams, have to eliminate the 
enemy team or detonate a bomb in their base. 

28Valve Software, 2000 

Infinity Ward, 2003 
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Figure 2.1: Visual representation of Qlsted et al.[1] generative process. 


and Hold®° game mode, without compromising the quality of the final output. 
To achieve this, they employ a genetic approach, which fitness function is 
evaluated directly on the topology of the map, considering four different 
factors: the connectivity between regions, the number of points of collision, 
the balancing in the positioning of control points and spawn points. With 
no need to simulate matches, this process can be completed in a matter 
of seconds. The algorithm starts by generating three maps, that are then 
evolved by mutation. To obtain the initial maps, Anand and Wong populate 
a grid with random tiles, they clean it of undesired artifacts and they identify 
regions within it, that are then populated with strategic points, resources, 
spawn points and covers. Despite its good results, this approach heavily 
relies on the validity of the selected topological metrics and, as we have seen, 
it is still not clear which the good elements of a level are. 


Finally, Cachia et al.[2] extended search-based procedural generation to 
multi-level maps, generating the ground floor with one of the methods defined 
by Cardamone and employing a random digger for the first floor. The final 
result can be seen in figure 2.2. Their algorithm also positions spawn points 
and resources through a topological fitness function, which entails the same 
problems described for Anand and Wong’s approach. 


30A multiplayer game mode where players, divided in two teams, fight for the control of 
some strategic areas. The score of each team increases over time proportionally to the 
number of controlled points until one of the two teams reaches a given limit, winning 
the game. 
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Figure 2.2: One of the maps evolved by Cachia's et al.[2] algorithm. 


2.4 History of Level Design in FPS 


First Person Shooter are a video game genre which main features are the 
first-person player perspective and a weapon-based combat gameplay. Dur- 
ing the years this genre has been consonantly evolving, as new elements 
started to emerge from the very aggressive and fast-paced gameplay of the 
first games of this kind, like Doom*!. Games like Half-Life?” highlighted the 
importance of the story and of the setting, games like Deus Ex*% introduced 
role-play and stealth mechanics and games like Quake III: Arena?! and Un- 
real Tournament? moved the focus from single player to multiplayer. Finally, 
Modern Military Shooters introduced a slower and more realistic gameplay 
and radically changed the setting from fictional conflicts to contemporary 
ones. 


2.4.1 Level Design evolution in FPS 


The evolution of the mechanics of this genre was supported by a constant 
refinement of level design and of the used tools. 


311D Software, 1993. 

32 Valve Software, 1998. 
33Ton Storm, 2000. 
34id Software, 1999. 
35Epic Games, 1999. 
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Before 1992: The first FPS 


The origin of the FPS genre goes back to the beginning of video games 
themselves. In 1973, Steve Colley developed Maze War, a simple black-and- 
white multiplayer game set in a tile-based maze, where players would search 
for other players’ avatars, killing them to earn points. Around the same time, 
Jim Bowery created Spasim, a simple first-person space flight simulator. Both 
games were never released, instead, we must wait the beginning of the 80’s to 
see the first products available to the public. Heavily inspired by Colley and 
Bowerey’s work, these games had almost no level design, but during the years 
they started to become a little more complex, with tangled sci-fi structures 
taking over mazes. 


1992: Wolfenstein 3D defines a new genre 


When Wolfenstein 3D*% was released in 1992, it changed the genre forever, 
thanks to its fast gameplay and its light game engine, that allowed to target 
an audience as wide as possible. Wolfenstein 3D took up the exploitative 
approach of the period, with its levels full of items, weapons and secret 
rooms. The level design was still simple, because the technical limitations 
of the engine and of its tile-based?” top-down* level editor allowed to create 
only flat levels, with no real floor or ceiling and walls always placed at a right 
angle. 


1993 - 1995: Doom and its legacy 


A year later, id Software released Doom, a milestone in the history of the 
genre. The game engine of Doom was capable of many innovations: sec- 
tions with floor and ceiling with variable height, elevators, non-orthogonal 
walls, interactive elements, lightning, even dynamic, textures for horizon- 
tal surfaces and even a simple skybox3”, all of this without losing the speed 
that characterized Wolfenstein. The developers took advantage as much as 
possible of the capabilities of the engine, achieving a level design way more 
complex than what had been seen before. In addition, Doom was designed to 
be easily modifiable by the users and featured cooperative and competitive 


36d Software, 1992. 

37The map consists in a grid composed by squared cells, or tiles, of equal size. 

38In top-down games and editors, the game world is seen from above. 

39 A method of creating backgrounds that represent scenery in the distance, making the 
game world look bigger than it really is. 
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multiplayer, via LAN or dial-in connections, that rapidly gathered a massive 
user base. 

The impact of Doom on the genre was so strong that in the following years 
the market was flooded with its clones. All these games, as well as Doom, 
had still some technical limits, in their engines, that were not completely 
3D, in their level editors, that were still top-down and did not allow for the 
design of more complex levels, and in their gameplay, that still faced limited 
movements. 


1996 - 2000: A constant evolution 


In the next years, many games continued what Doom started, bringing con- 
stant improvements to the genre. Duke Nukem 3D% set aside the sci-fi 
settings of its predecessors, switching to real locations, inspired by the ones 
of Los Angeles. This was possible thanks to its 2.5D engine Build, that 
provided a What You See Is What You Get* level editor. Furthermore, 
Build allowed to apply scripts to certain elements of the map, resulting in a 
more interactive environment. 

Released in 1996, Quake** was one of the first and most successful FPS 
with a real 3D engine, that allowed an incredible jump forward in terms 
of realism, level design and interactivity. Quake had also a rich multiplayer, 
with a lot of maps, game modes and special features, like clans and modding. 
Two years later, Unreal brought a new improvement in terms of realism 
and level design, thanks to its engine capable of displaying huge outdoors 
settings. 

In those years many new sub-genres started to spawn, obtained by em- 
phasizing certain features of the previous games or by borrowing mechanics 
from other genres. Quake III Arena” and Unreal Tournament! were some 
of the first and most successful multiplayer games ever released, that re- 


403D Realms, 1996. 

414 2.5D engine renders a world with a two dimensional geometry in a way that looks 
three-dimensional. An additional height component can be introduced, allowing to ren- 
der different ceiling and floor height. This rendering technique limits the movements of 
the camera only to the horizontal plane. Doom and many similar games employed this 
technology. 

Developed by Ken Silverman in 1995. 

43In computer science, What You See Is What You Get denotes a particular kind of editors 
where there is no difference form what you see during editing and the final output. 

44id Software, 1996. 

Epic Games, 1998. 

46id Software, 1999. 

47Epic Games, 1999. 
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quired a new approach to level design, completely focused on the creation 
of competitive maps. Games like Deus Ex introduced tactical and RPG ele- 
ments, with the possibility of reaching an objective in multiple ways, thanks 
to a level design that exalted the freedom left to player. Finally, Half-Life 
changed forever the approach of this genre to storytelling and to level design: 
the game puts great emphasis on the story, that is narrated from the eyes 
of the player, without cut-scenes, and introduces the possibility of moving 
freely between areas, with no interruption. The game also set new standards 
with its challenging enemy AI, capable of taking advantage of the terrain and 
coordinating flanking maneuvers. 


2001: The rise of console shooters 


In 2001, Halo: Combat Evolved* revolutionized the genre, introducing some 
of the mechanics on which modern FPS are based, as the limited amount 
of weapons that the player can carry and the regeneration of health over 
time. This slower and more strategic approach to gameplay matched per- 
fectly with consoles and their twin-stick-controllers, that were not suitable 
for the extremely fast paced action of the past. Over time, this new approach 
to gameplay overshadowed almost completely all the others, thanks to the 
diffusion of consoles and to the increase of production costs, that made PC 
exclusives economically disadvantageous. From the standpoint of level de- 
sign, this change required to increase the complexity of the levels and the 
addition of strategically placed covers. 


Today: A time of stagnation 


Starting from its origins, level design undergone a radical evolution, but in 
the last years it has shown no significant improvements. This could be due 
to the considerable risk associated with modern projects or to the lack of 
suitable instruments. 


2.5 Graph Theory in video games 


Graph Theory has always been used in video games, usually as a useful tool 
to perform pathfinding for artificial agents. These techniques revolve around 
the creation of a navigation mesh, i.e. a representation of the walkable areas 
of a level using non-overlapping polygons obtained by removing the shapes 


48Bungie, 2001. 
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Figure 2.3: A common pathfinding process. 


of obstacles from the considered surface. The result is then used to generate 
a graph, selecting as nodes the vertices or the centers or the centers of edges 
of the obtained polygons, depending on the kind of movement that must be 
achieved. This graph can be pre-generated or computed at run-time, if the 
technique is applied to dynamic environments. Finally, an algorithm like A * 
is employed to find the shortest path between two points. This process can 
be seen in figure 2.3 

Graphs are also used in procedural generation, as an effective tool to 
model landmasses and roads. 


2.6 Summary 


In this chapter we analyzed the current state of level design for First Person 
Shooters and how this field has been explored in academic research. We 
then introduced Procedural Content Generation and we observed how some 
studies have proved that it is a suitable method to produce maps for FPS 
games. We also took a brief look at the history of First Person Shooters, 
analyzing how level design evolved over time. Finally, we depicted some of 
the most common uses of Graph Theory in video games. 
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Map design and generation 
framework 


In this chapter we describe the framework that we have developed to study 
the design and generation of maps for multiplayer Firsts Person Shooters. 
After a quick overview, we present the map formats that the framework 
supports and we extensively analyze its structure, its components and its 
features. 


3.1 Description of the framework 


We designed our framework with the objective of providing a valid alterna- 
tive to the games currently employed in this research field. All the available 
options, like Cube 2: Sauerbraten, are powerful tools to perform studies in- 
volving artificial agents, but they are not suitable for user-based studies. A 
data-collection campaign based on these games requires either downloading 
the game or taking part in real-life play-test sessions, but these options dis- 
courage potential participants because they are significantly time-consuming. 
For this reason, we decided to develop a Unity! framework that is as light as 
possible, with a WebGL build weighting less than 10MB that can be played 
using any browser. 

Since the purpose of this tool is to be used in research, we decided to 
support most map representation formats used in previous works and we 
designed our framework to be as modular, expansible and configurable as 
possible. 


!Unity Technologies, 2005. Unity is a game development environment that includes a 
game editor and a game engine. Currently, it is the most used game development tool. 
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3.2 Map representation 


Maps are structured as grids of orthogonal tiles and are internally repre- 
sented by matrices of characters, where each cell corresponds to a specific 
tile. Depending on the character it contains, a cell can represent a wall, a 
floor or an object on the floor. If a cell corresponds to a wall tile we say it 
is filled, if it corresponds to a floor tile we say it is empty. The framework 
supports multi-level maps, which are represented by lists of matrices, with 
each matrix corresponding to a level. 

The framework allows to represent maps in two more formats, that are 
converted to the internal one when provided as input. 


3.2.1 Text representation 


The text representation allows to encode the map as a text, of which each line 
corresponds to a row of the internal matrix representation and each character 
corresponds to a cell. For multi-level maps, the format is the same, with the 
exception of blank lines used to separate the floors, that are encoded from 
the lower one to the higher one. 


3.2.2 All-Black representation 


Our All-Black representation is an extended version of the one defined by 
Cardamone et al.[12], to which we have added the support for objects and 
multi-level maps. In their work, the All-Black representation encodes the 
empty areas of an otherwise filled map, consisting in square rooms and cor- 
ridors of fixed width. Rooms are defined by (x,y,s) triplets, where x and 
y define the coordinates of the center of the room and s defines its width. 
Corridors are rectangular areas with a fixed width of 3 cells and are defined 
by (z,y,!) triplets, where x and y define the point in which the corridor 
starts and / defines its length. l also provides the direction of the corridor: if 
l is positive the corridor extends along the x-axis, otherwise it extends along 
the y-axis. With respect to this representation, we changed the encoding 
of the rooms by considering x and y as the coordinates of the corner closer 
to the origin; this change allows to remove any ambiguity deriving from the 
position of the center of a room of even width. 

For allowing the encoding of objects, we added a third kind of triplet, 
(x,Y,0), that uses x and y to denote the coordinates of the tile that hosts 
the objects and o to denote the object itself, encoded as a character. In our 
representation, first we store the triplets representing the rooms, then the 
triplets representing the corridors and finally the triplets representing the 


18 


3.2. Map representation 


(a) Map represented by (5, 5, 9) (10, (b) Map represented by (1, 2, 5) (4, 
10, 7) (15, 25, 3) | (5, 15, 15) (11, 6,8) | (5, 6, —10) (10, 15, —6) | (3, 
15, —7) | (5, 5, 5) (7, 7, d). 7, s) 1, 1, d). 


Figure 3.1: Two simple maps with their All-Black representation. 


objects. These groups are separated by the special character “|” and can 
have any number of elements, with the exception of the one denoting the 


rooms, that must have at least one triplet. 


We extended the All-Black representation by also including the one de- 
fined by Cachia et al.[2], that allows to encode maps generated with a random 
digger algorithm, i.e. an algorithm that randomly moves in a filled map emp- 
tying all the cells it crosses (for more details see subsubsection 3.3.3.2). The 
map is encoded by a quintuple (f,/,r,v,s), where f encodes the probabil- 
ity of moving forwards, l encodes the probability of turning left, r encodes 
the probability of turning right, v encodes the probability of jumping to a 
visited cell and s encodes the probability of placing a flight of stairs, if in a 
multi-level setting. With respect to the representation defined by Cachia et 
al., we added the possibility of encoding objects, which group of triplets is 
separated by the digger quintuple by the special character “|”. 


Multi-level maps are represented by encoding the floors from the lower 
one to the higher one using one of the two single-level All-Black formats that 
we have defined. The encoding of different floors are separated using the 
double special characters “||”. 


Figure 3.1 shows two maps with their All-Black representation. 
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3.3 Framework structure 


The framework collects data by assigning to the users matches to play. A 
match is defined by the game mode and by the map type, which in turn is 
defined by the map topology and by the map appearance. The map topology 
defines how the map is going to be and depends on the algorithm used to 
generate it, whereas the map appearance defines how the map is going to 
look and depends on how the map is assembled. This implies that the map 
type defines a whole array of procedurally generated maps that share the 
same topology and appearance. Therefore, when referring to a match we are 
considering a specific game-mode played in a procedurally generated map. If 
needed, it is possible to use a pre-generated map instead of generating a new 
one, by providing it as input using one of the supported formats. In this case 
the map topology defines how to interpret the input, that is then displayed 
considering the map appearance. 

A match is defined by combining different modules, called Managers, each 
of which controls a different aspect of the match. 


3.3.1 The Game Manager 


The Game Manager is the module responsible for the overall behavior of a 
match. Each game mode consists in a different version of the Game Manager. 
It leans on the Map Manager for the generation and the assembly of the 
map and on the Spawn Point Manager for the spawn of entities. The Game 
Manager controls the life-cycle of the match, that can be divided in the 
following phases: 


e Setup: all the modules are initialized. 


e Generation: the Map Manager generates or imports the map and as- 
sembles it. 


e Ready: the Game Manager displays a countdown announcing the start 
of the game. 


e Play: the Game Manager handles the game while the Experiment Man- 
ager logs the actions of the player, if needed. This phase continues until 
an end condition is satisfied. 


e Score: the Game Manager stops the game and displays the final score. 
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3.3.2 The Map Manager 


The Map Manager controls the generation, the import and the assembly 
of the map and the displacement of objects inside it. It leans on the Map 
Generator for the generation, on the Map Assembler for the assembly? and 
on the Object Displacer for the displacement?, whereas it performs the import 
itself. If the map is provided in input as a text file, the Map Generator is 
not called, whereas it is used to perform decoding if the map is provided in 
All-Black format. 


The framework provides three different versions of the Map Manager. 


3.3.2.1 Single-Level Map Manager 


The Single-Level Map Manager is used for any kind of single level map. It 
can generate maps, import them from file or decode them from All-Black 
format. 


3.3.2.2 Multi-Level Map Manager 


The Multi-Level Map Manager is used for any kind of map that has more than 
one floor. It can generate multi-level maps or import them from file, but it 
cannot perform All-Black decoding. In addition to the standard modules, it 
employs a Stairs Generator to position flight of stairs to connect the different 
floors. 

Multi-level maps are obtained by using at least one generator to produce 
the desired number of floors. Since this allows to combine different kind 
of generators, we were able to obtain maps similar to the ones evolved by 
Cachia et al.[2] (see figure 3.2a), as well as maps with a more complex and 
interesting layout than the ones obtained by previous works (see figure 3.2b). 


3.3.2.3 All-Black Multi-Level Map Manager 


The All-Black Multi-Level Map Manager is used to decode multi-level maps 
saved in All-Black format. If no stairs are found among the objects, it em- 
ploys the Stairs Generator to position them. 


2With assembly we mean the operation of creating a 3D model of the map starting from 
its matrix representation. 

3With displacement we mean the operation of placing the 3D models of the objects in 
the assembled map, according to their position defined by the Map Generator trough a 
positioning algorithm. 
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(a) Multilevel map which floors have (b) Multilevel map which floors share 
different topologies. the same topology. 


Figure 3.2: Two multilevel maps. 


3.3.3 The Map Generator 


The Map Generator controls the generation of the map. Each version of 
the Map Generator defines a different map topology depending on the used 
generation algorithm and on how its parametric settings are tuned. Some 
of these settings are shared by all the versions, whereas some of them are 
version-specific. 

The shared settings are used to define the size of the map and its encoding, 
to define the objects and to impose some constraints on their positioning: 


e Width: the number of rows of the matrix that represents the map. 
e Height: the number of columns of the matrix that represents the map. 


e Object ToObjectDistance: the minimum number of cells that must sep- 
arate two objects. 


e ObjectToWallDistance: the minimum number of cells that must sepa- 
rate an object and a wall. 


e BorderSize: the width of the border placed all around the map once it 
has been generated, expressed in number of cells. 


e RoomChar: the character used to represent a clear cell where the player 
can walk. 
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e WallChar: the character used to represent a filled cell where the player 
cannot walk. 


e MapObjects: a list of the objects that must be placed in the map. 


The objects contained in MapObjects can represent spawn points, resources 
or decoration. They have the following properties: 


e ObjectChar: the character used to represent the object. 


e NumObjPerMap: the number of objects of that kind that must be 
placed in the map. 


e PlaceAnywhere: if this value is set to true, the restriction on the dis- 
tance from the walls is ignored. 


e PositioningMode: the algorithm used to position the object in the map. 


The framework provides three different algorithms to position the objects 
inside the map: 


e Rain: positions the objects selecting random cells from the ones that 
are empty and satisfy the ObjectTo WallDistance constraint. 


e Rain Shared: positions the objects selecting random cells from the ones 
that are empty and satisfy the Object To WallDistance constraint and 
the Object ToObjectDistance constraint on the objects that have been 
placed using Rain Shared. 


e Rain Distanced: positions the objects selecting random cells from the 
ones that are empty and satisfy the Object To WallDistance constraint 
and the ObjectToObjectDistance constraint on the objects with the 
same ObjectChar. 


All of the following versions of the Map Generator are deterministic, since 
they require a seed value as input that constrains the output to a specific 
map. 


23 


Chapter 3. Map design and generation framework 


3.3.3.1 Cellular Generator 


The Cellular Generator employs a parametric cellular automaton* to gener- 
ate a natural looking map. 

The algorithm starts by filling some tiles of the map selected at random, 
then it applies the cellular automaton for a certain number of generations 
and finally it performs some refinements (for more details, see algorithm 1). 
The resulting topology depends on the following parameters: 


e RandomFillPercent: the percentage of tiles that are randomly filled 
during the initialization of the algorithm. High values promote narrow 
spaces, small values promote wide areas. 


e SmoothingInteration: the number of generations the cellular automaton 
is ran for. High values penalize small features and make the walls 
smoother. 


e NeighbourTileLimitLow: the maximum number of neighbors a cell must 
have to became empty. Its value must be lesser or equal than the one 
of NeighbourTileLimitHigh. The map becomes noisier the more they 
diverge. 


e NeighbourTileLimitHigh: the minimum number of neighbors a cell 
must have to became filled. 


e WallThresholdSize: the minimum number of cells that an isolated filled 
region must include to not be deleted. High values penalize small filled 
regions. 


e RoomThresholdSize: the minimum number of cells that an isolated 
void region must include to not be deleted. High values penalize small 
empty regions. 


e PassageWidth: the width of a passage connecting two different areas, 
expressed in number of cells. 


Figure 3.3 shows how these parameters influence the topology of a map. 
The Cellular Generator can perform import and export using the text 
representation. 


tA cellular automaton consists of a grid of cells, each in one of a finite number of states, 
such as on and off. For each cell, a set of cells called its neighborhood is defined, usually 
composed by the ones that share at least one vertex with it (referred as 8-neighbors). 
Given the current state of the grid, a new generation is created, according to some fixed 
rule that determines the new state of each cell depending on the current state of the cell 
and of its neighbors. 
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3.3.3.2 Divisive Generator 


The Divisive Generator employs a binary space partitioning algorithm to 
generate a man-made looking map. 

The algorithm starts by obtaining partitions of the map by recursively 
dividing it in two sides of random size along one of the axes, then it selects 
some of these partitions as rooms and finally it connects them with corridors 
(for more details, see algorithm 2). The resulting topology depends on the 
following parameters: 


e RoomDivideProbability: probability of a partition being divided again. 
High values promote small rooms. 


e MapRoomPercentage: minimum percentage of tiles of the map that 
must be empty. High values promote close rooms separated by walls, 
low values promote distant rooms connected by corridors. 


e DivideLowerBound: minimum division point expressed as percentage 
of the dimension of the room. 


e DivideUpperBound: maximum division point expressed as percentage 
of the dimension of the room. 


e MinimumRoomDimension: minimum width expressed in number of 
cells that a partition must have to be divided again. High values pro- 
mote large rooms. 


e MinimumDepth: the minimum number of recursive divisions that each 
partition must have experienced. 


e PassageWidth: the width expressed in number of cells of the corridors 
connecting the rooms. 


e MaxRandomPassages: the number of additional corridors to place, if 
possible, once that all the rooms are connected. 


Figure 3.4 shows how these parameters influence the topology of a map. 

The Divisive Generator can perform both import and export using the 
text representation, whereas the All-Black format is used only for export. 
The latter matches perfectly with this generator, since both are based on the 
concept of rooms and corridors. 
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3.3.3.3 Digger Generator 


The Digger Generator employs a simple algorithm to generate a man-made 
looking map. 

The algorithm is iterative and its state is defined by the current cell 
and by the current direction, that together with a randomly selected action 
determine the next cell that the algorithm is going to visit. Starting from the 
central cell of a filled map, at each iteration the algorithm empties the current 
cell and randomly decides if moving forward, turning left, turning right, 
jumping to a random visited cell or placing a flight of stairs, if controlled 
by a Multi-Level Generator. The algorithm stops when a certain percentage 
of cells has been emptied. The resulting topology depends on the following 
parameters: 


e ForwardProbability: probability of moving forward in the next itera- 
tion. High values promote long corridors. 


e LeftProbability: probability of moving leftward in the next iteration. 
High values promote wide areas. 


e RightProbability: probability of moving rightward in the next iteration. 
High values promote wide areas. 


e VisitedProbability: probability of jumping to a visited cell in the next 
iteration. High values promote a more complex topology. 


e StairProbability: probability of placing a flight of stairs. 
e RoomPercentage: percentage of tiles of the map that must be empty. 


Figure 3.5 shows how these parameters influence the topology of a map. 
The Digger Generator can perform both import and export using the text 
representation, whereas its own All-Black format is used only for import. 


3.3.3.4 All-Black Generator 


This simple generator parses inputs expressed in All-Black format, extracting 
rooms and corridors. If no objects are specified, it adds them to the map. 


3.3.4 The Stairs Generator 


The Stairs Generator places stairs in the map after having analyzed it to 
find possible positions, but if stairs have already been placed by the Map 
Generator (this happens with the Digger Generator), it just validates them. 
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Algorithm 1: Cellular generation algorithm. 


for every cell in the map do 
empty the current cell; 
end 
while percentage of filled cells < RandomFillPercent do 
select a random cell; 
fill the selected cell; 
end 
for generation from 0 to SmoothingIterations do 
for every cell in the map do 
count the 8-neighbors of the cell; 
if 8-neighbors count > NeighbourTileLimitLow then 
| mark the current cell as filled for the next generation; 
end 
if 8-neighbors count < NeighbourTileLimitHigh then 
| mark the current cell as empty for the next generation; 
end 


end 

update the map to the next generation; 

end 

for every isolated region of empty cells do 

if #cells in the region < RoomThresholdSize then 
| fill all the cells in the region; 

end 

end 

for every isolated region of filled cells do 

if #cells in the region < WallThresholdSize then 
| empty all the cells in the region; 

end 


end 
connect all the regions composed by empty cells; 
place the objects; 


This algorithm is a modified version of the one proposed by Sebastian Lague[16]. 
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(a) Cellular map gener- (b) Cellular map gener- (c) Cellular map gener- 
ated with the default set- ated with RandomFill- ated with RandomFill- 


tings. Percent = 40%. Percent = 50%. 

(d) Cellular map gener- (e) Cellular map gener- Cellular map gener- 
ated with SmoothingIt- ated with SmoothingIt- = with WallThresh- 
erations = 0. erations = 3. oldSize = 5. 


Figure 3.3: Six maps generated by the Cellular Generator using “ANotSo- 
RandomSeed” as seed, but different settings. By default, the Cellular Gener- 
ator has RandomFillPercent set to 45%, SmoothingIterations set to 2, Neigh- 
bourTileLimitHigh set to 4, NeighbourTileLimitLow set to 4, Wall Threshold- 
Size set to 40 and RoomThresholdSize set to 100. 
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Algorithm 2: Divisive generation algorithm. 


for every cell in the map do 
| fill the current cell; 

end 

initialize the partitions list; 

DivideRoom(map, 0); 

while percentage of empty tiles < MapRoomPercentage do 
extract a partition from the partitions list at random; 
make the partition a room; 
empty the tiles in the room; 

end 

connect the rooms; 

while all the rooms are not directly connected and placed 


additional corridors < MaxRandomPassages do 
add an additional corridor between two rooms selected at 
random; 
end 
place the objects; 


Function DivideRoom(section, depth) is 
if (true with probability roomDivideProbability and partition 
width > minimumDividableRoomDimension and partition 
heigth > minimumDividableRoomDimension) or depth < 
minimumDepth then 
if previous division was horizontal then 
perform a random vertical division between 
| divideLowerBound and divide UpperBound; 
else 
perform a random horizontal division between 
| divideLowerBound and divideUpperBound; 
end 
DivdeRoom (first sub-section, depth + 1); 
DivdeRoom (second sub-section, depth + 1); 
else 
add the partition to the partitions list; 
end 


end 
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A 


(a) Divisive map gener- Divisive map gener- (c) Divisive map gen- 
ated with the default set- He with RoomDivide- erated with Minimum- 
tings. Probability = 20%. Depth = 1. 

Divisive map gen- (e) Divisive map gen- Divisive map gen- 
ci with Minimum- erated with Minimum- è with Minimum- 
Depth = 8. RoomDimension = 1. RoomDimension = 7. 


Figure 3.4: Six maps generated by the Divisive Generator using “AModer- 
atelyRandomSeed” as seed, but different settings. By default, the Cellular 
Generator has RoomDivideProbability set to 80%, MapRoomPercentage set 
to 90%, DivideLowerBound set to 10%, DivideUpperBound set to 90%, Min- 
imumRoomDimension set to 3, MinimumDepth set to 4, Passage Width set 
to 3 and MaxRandomPassages set to 12. 
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da ai 


a) Digger map generated with the de- b) Digger map generated with Room- 
Li settings. de = 20%. 
(c) Digger map generated with For- ) Digger map generated with For- 


wardProbability = 60%, RightProba- ee = 96%, Right Proba- 
bility = 19% and LeftwardProbabili- bility = 1% and LeftwardProbabili- 
ty = 19%. ty = 1%. 


Figure 3.5: Four maps generated by the Digger Generator using “ AFairlyRan- 
domSeed” as seed, but different settings. By default, the Digger Generator 
has ForwardProbability set to 90%, LeftProbability set to 4%, Right Probabil- 
ity set to 4%, VisitedProbability set to 2%, StairProbability set to 0% and 
RoomPercentage set to 50%. 
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3.3.5 The Map Assembler 


The Map Assembler controls the assembly of the map. Each version of the 
Map Assembler corresponds to a different map appearance. 


3.3.5.1 Mesh Assembler 


The Mesh Assembler produces a 3D model of the map using an implemen- 
tation of the marching squares algorithm? to generate three meshes: one for 
the floor, one for the walls and one for the ceiling. As it can be seen in figure 
3.7a, the result is a natural-looking environment. 


3.3.5.2 Prefab Assembler 


The Prefab Assembler produces a 3D model of the map by associating to 
each tile a specific 3D model, or prefab, depending on the value of the tile 
and of its 8-neighbors (see figure 3.6). Figure 3.7c shows a map assembled 
with this algorithm. 


3.3.5.3 Multi-Level Prefab Assembler 


Like the Prefab Assembler, the Multi-Level Prefab Assembler produces a 3D 
model of the map by combining prefabs, but it employs additional logic to 
manage the overlap of multiple floors. Figure 3.7d shows a map assembled 
with this algorithm. 


3.3.6 The Spawn Point Manager 


The Spawn Point Manager contains a list of all the spawn points displaced 
in the map, that is populated at the end of the generation phase by the 
Game Manager. When the Game Manager needs to spawn an entity, the 
Spawn Point Manager provides a random spawn point from the ones that 
have not been used in a certain amount of time. If no spawn point meets 
this condition, the extraction is performed from the complete pool. 


3.3.7 The Object Displacer 


The Object Displacer associates a character that represents neither a wall 
or a clear cell to the corresponding object, displacing it at the coordinates 
defined by its position in the map matrix. During this process, it populates 


5 Marching squares is a computer graphics algorithm that generates contours for a two- 
dimensional scalar field, i.e. a rectangular array of individual numerical values. 
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Figure 3.6: Some prefabs and the masks they are associated to. Each model 
refers to the central cell of the corresponding mask. Green denotes empty 
cells, red denotes filled cell, half-green and half-red denotes cells that are 
ignored by the mask. The masks can be rotated to obtain all the possible 
configurations. 
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(a) Map generated with the Cellu- (b) Map generated with the Digger 
lar Generator and assembled with the Generator and assembled with the 
Mesh Assembler Mesh Assembler 


(c) Map generated with the Divisive (d) Multi-level map assembled with the 
Generator and assembled with the Pre- Prefab Assembler 
fab Assembler 


Figure 3.7: Some possible combinations of generators and assemblers. 
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a dictionary containing all the objects in the map divided by category, that 
is used by the Game Manager to populate the list of spawn points used by 
the Spaun Point Manager. 


3.3.8 The Experiment Manager 


The Experiment Manager is a stand alone module that allows to create and 
manage the experiments used to perform user-based validation. Once that an 
experiment has been defined, the Experiment Manager automatically assigns 
to the users the matches to play and collects the desired information. 


Experiment definition 


An experiment is defined by a tutorial, a list of studies and a survey. 

The tutorial is optional and consists in a match with a simple objective 
used to explain the commands to the user. 

The studies are not optional and each one of them consists in a list of 
cases. Each case contains a pool of maps and a single game mode, that is 
used to play the maps in the pool. The maps in the pool are the object of 
validation, whereas the game mode is the employed validation method. 

The survey is optional and consists in a list of multiple-choice questions 
that are presented to the player at the end of the experiment. 

All these elements can be easily customized, as well as the number of 
test cases that an user has to play in a single experiment session, defined 
by the parameter CasesPerUsers. The Experiment Manager also allows to 
diagonally flip the maps, which is an useful method to avoid the rise of a bias 
due to memorization when the player is presented with different versions of 
the same map. 


Experiment management 


Once that the experiment has been defined, it is ready to be played by the 
users. 

Each time that a user participates in the experiment, the Experiment 
Manager selects the least played case of the least played study, in a round- 
robin fashion. This allows to have equally distributed data for each study 
and is possible thanks to the completion tracking provided by the Experiment 
Manager itself. Then, for each case that the user is going to play, a pre- 
generated map is extracted from the pool and presented to the player as a 
match of the game mode specified by the case. In a complete experiment, the 
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player will consecutively play the tutorial, one ore more matches and finally 
answer the survey. 

The experiment can be performed offline or online. In the former, the 
computed data and the experiment completion are stored locally, whereas 
in the latter, they are stored on a server. If the experiment is provided via 
an executable, then it is possible to configure it as offline, online or both, 
with the completion that is stored on a server and the computed data that 
is stored both locally and remotely. If the experiment is provided via a web 
build playable via browser, the only supported configuration is the online 
one. 


Logging 


By default, the Experiment Manager produces a complete log of each match, 
saving the following information: 


e MapInfo: this field contains general information about the map fea- 
tured in the match, as its name, its dimension, the size of its tiles and 
if it has been flipped. 


e Gamelnfo: this field contains general information about the match, as 
the experiment name, the game mode and the duration. 


e SpaunLogs: this field contains a list of all the spawn events. Each entry 
contains a timestamp, the coordinates of the spawn point and the name 
of the spawned entity. 


e PositionLogs: this field contains a discretized list of the positions occu- 
pied by the player during the match, acquired with a given frequency. 
Each entry contains a timestamp, the coordinates of the player and the 
direction he is facing expressed in degrees. 


e ShotLogs: this field contains a list of all the shots fired by the player. 
Each entry contains the same fields of the PositionLogs, plus the iden- 
tifier of the firing weapon, the number of projectiles in its magazine 
and its total available ammunition. 


e ReloadLogs: this field contains a list of all the reloadings performed 
by the player. Each entry contains a timestamp, the identifier of the 
weapon that is being reloaded, the number of projectiles in its magazine 
and its total available ammunition, both before the reloading. 
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e HitLogs: this field contains a list of all the shots that hitted an entity. 
Each entry contains a timestamp, the coordinates of the hitted entity, 
the name of the hitted entity, the name of the hitter entity and the 
caused damage. 


e KillLogs: this field contains a list of all the killings. Each entry contains 
a timestamp, the coordinates of the killed entity, the name of the killed 
entity and the name of the killer entity. 


It is possible to customize the Experiment Manager to have it compute 
and save specific metrics in a different log. Moreover, if the experiment 
includes a survey, the answers of the user are saved in a dedicated log. 


Data retrieval 


The framework provides a simple interface for downloading the logs stored 
on the server. Since it is possible to set a limit on the dimension of logs 
which causes them to be split in multiple parts, the framework automatically 
performs merging and signals incomplete logs. 


3.4 Entities 


The entities are the agents that take part in a match. All the entities share 
the following common features: 


e TotalHealth: the maximum number of health points of the entity, i.e. 
the quantity of damage the entity can receive before being destroyed. 


e Guns: the guns associated to the entity. 
The framework includes three different kind of agents: 


e Player: the entity that is controlled by the user. It can walk, jump, 
aim, deal and receive damage and pick resources. 


e Opponent: this entity is similar to the one of the Player, but in the 
current version of the framework it has no active logic, beside the one 
that controls its health. 


e Target: this simple entity rotates in place. Besides receiving damage, 
it can harm the player thanks to the laser gun it can be equipped it. 
Figure 3.10 shows different kind of targets. 
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Figure 3.8: Different ready-to-use target entities provided by the framework. 
From the first to the third are simple targets, from the fourth to the sixth 
are targets equipped with two opposing laser guns, from the seventh to the 
ninth are“core” targets equipped with an increasing number of radial laser 
guns. The size of each target is proportional to its TotalHealth. 


3.5 Weapons 


The framework allows to easily define any kind of fire arm starting from a 
common parametric structure that characterizes the basic behavior of a gun 
with the following variables: 


e Damage: the damage inflicted by a single projectile. 


e Dispersion: the aperture of the cone-shaped projectile spread expressed 
in degree. 


e ProjectilePerShot: the number of projectile emitted with one shot. 
e InfiniteAmmo: tells if the gun has infinite ammunition. 
e ChargerSize: the capacity of the gun magazine. 


e MarimumAmmo: the maximum quantity of ammunition that can be 
carried for a specific gun. 


e ReloadTime: the amount of time needed to reload the gun. 
e CooldounTime: the amount of time needed after a shot to fire again. 
e AimEnabled: tells if the gun allows the player to aim. 


e Zoom: the zoom provided by the scope when aiming. 


This parametric approach allows to use the framework as a tool for user- 
based validation of procedurally generated weapons, that is another research 
field that has been explored in recent years [17]. 

The framework comes with three different categories of weapons already 
implemented. 
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Raycast guns 


Raycast guns are weapons which projectiles have no time of flight, but in- 
stantly hit the target once shot. The only additional parameter that this 
category introduces is Range, which can be used to limit the reach of the 
weapon. 

There are three weapons of this category that the player can use: 


e Assault Rifle: a medium range weapon with a high fire rate, a capa- 
cious magazine and no dispersion which shots single medium damage 
projectiles. Figure 3.9a shows its model and table 3.1 shows its param- 
eters. 


e Shotgun: a short range weapon with a slow fire rate, a small maga- 
zine and high dispersion which shots multiple low damage projectiles. 
Figure 3.9b shows its model and table 3.1 shows its parameters. 


e Sniper Rifle: a long range weapon with a slow fire rate, a small mag- 
azine and no dispersion which shots single high damage projectiles. It 
is equipped with a scope. Figure 3.9d shows its model and table 3.1 
shows its parameters. 


Projectile guns 


Projectile guns are weapons that shoot projectiles with a limited flight speed. 
This category introduces two additional parameters: 


e ProjectileLifetime: if the projectile does not hit anything after this 
amount of time, it is destroyed. 


e ProjectileSpeed: the speed of the projectile. 


The only weapon of this category that the player can use is the Rocket 
Launcher, a long range weapon with a slow fire rate, a small magazine and no 
dispersion which shots explosive projectiles. The projectiles of this weapon 
are slow and explode on impact, dealing an high damage that decreases 
radially from the center of the explosion. Figure 3.9c shows its model and 
table 3.1 shows its parameters. 
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ro — 


) The Assault Rifle. (b) The Shotgun. 
) The Rocket Launcher. (d) The Sniper Rifle. 


Figure 3.9: The weapons that the player can use. 


Assault Shotgun Rocket Sniper 
Rifle Launcher Rifle 
Damage 15 20 120 75 
Dispersion 0 7.5 0 0 
ProjectilesPerShot 1 5 1 1 
InfiniteAmmo false false false false 
Charger Size 32 3 2 5 
MaximumAmmo 120 24 16 30 
Reload Time 1 1 1 1 
Cooldown Time 0.1 0.75 0.75 0.5 
AimEnabled false false false true 
Zoom 1 1 1 3 
LimitRange false true - false 
Range - 100 - - 
ProjectileLifeTime - - 10 - 
ProjectileSpeed - - 50 - 


Table 3.1: Parametric configuration of the four weapons available to the 
player. 
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Laser guns 


Laser guns are not based on the same structure of the previous categories. 
Laser guns emit a continuous ray that deals damage over time to everything 
it touches. Their only configurable parameter is DPS (damage per second), 
i.e. the damage that the gun deals in a second when continuously hitting a 
target. 


3.6 Objects 


Beyond decorations, that are simple 3D models with no logic used to graph- 
ically enrich the map, the framework provides spawners, i.e. objects that 
spawn a resource that can be collected by the entities. Once that the resource 
is collected, it disappears for an interval of time defined by the parameter 
Cooldown. The framework comes with two different spawners: 


e Health pack Spauner: it spawns health packs, that partially restore 
the health of the entity. The healed amount of health is defined by 
RestoredHealth. 


e Ammunition Spawner: it spawns ammunition crates, that supply the 
entity with ammunition. SuppliedGuns defines which guns the crates 
can supply, whereas AmmoAmounts defines how many ammunition are 
provided to the entity for each supplied weapon. 


3.7 Game modes 


The framework comes with three different game modes, that have been de- 
signed to highlight specific aspects of a multiplayer FPS. Each game mode 
is defined by a different version of the Game Manager. 


3.7.1 Duel 


The Duel game mode is a classic deathmatch redistricted to two entities, 
with one of the two being the player. Each time that an entity eliminates 
the other one, it scores one point, whereas it loses one if it destroys itself 
by accident. When an entity has been eliminated, it respawns® at a random 


6In video games, respawn denotes the reappearing in a specific location, called spawn point, 
of an entity which has been eliminated. 
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Figure 3.10: Targets equipped with laser guns in the final wave of a Target 
Rush match. 


spawn point. At the end of the match, which is marked by a time limit, the 
winner is the contender who has scored the highest number of points. 

Of the game modes that the framework provides, this one is the most 
complete, because it contains all the dynamics that characterize a multiplayer 
FPS match, and the most important, since it is the one that is usually used 
to perform validation in this research field. 


3.7.2 Target Rush 


In the Target Rush game mode the player faces increasingly difficult waves 
of enemies, trying to obtain a score as high as possible before the end of the 
game, that is triggered by the player death or by the countdown hitting zero. 
The player earns points and additional time when he destroys an enemy or he 
completes a wave. The number of waves is parametric, as well as the content 
of each one. By default, this mode has twenty waves and uses targets as 
enemies, that start as harmless but became more and more numerous and 
dangerous with each wave (see figure 3.10). 

This game mode has been designed to force the player to explore the map, 
through the research of enemies, health packs and ammunition, that quickly 
become indispensable as the match progresses. 
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3.7.3 Target Hunt 


In the Target Hunt game mode the player needs to find and eliminate a series 
of enemies in a given amount of time. The enemies that the player is going 
to face are stored in a parametric list that is read circularly and are spawned 
one at a time, as soon as the previous one has been eliminated. To each 
enemy is assigned a score. 

This game mode has been designed to force the player to search a specific 
objective in the map. 


3.8 Summary 
In this chapter we analyzed the framework that we have developed to per- 


form user-based validation, focusing on its structure, its components and its 
parametric nature. 
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Graph-based map analysis 


In this chapter we describe the approach that we have developed to perform 
analysis and populating of pre-generated maps using Graph Theory. After a 
quick overview, we introduce the analysis capabilities of this approach and 
then we present how we employed it to strategically place game elements in 
pre-generated maps. 


4.1 Overview 


Our approach consists of generating different kind of graphs, starting from 
the text and the All-Black representation of a map, that are used to perform 
various analysis and manipulation operations. 

The use of All-Black format is convenient, because it provides by default 
a logical division of the map in different areas and it allows our approach to 
be applied by other researchers, since as we have seen the All-Black format 
is widely used in the literature. In this thesis we focused on positioning 
objects in pre-generated maps, but, for instance, the same approach could 
be used to address the identification and definition of design patterns from 
an unfamiliar perspective or for direct evaluation in Search Based PCG. 


4.2 Analysis of the map 
The analysis is performed by generating different kind of undirected graphs, 


each one used to highlight a different feature of the map in question, using a 
Python tool based on NetworkX* that we developed. 


1A solid graph theory library (https://networkx.github.io/). 
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4.2.1 Outlines graph 


The outlines graph is generated starting from the All-Black representation 
of a map and is obtained by associating a node to every vertex of every 
room and corridor and by connecting the non-adjacent ones that belong to 
the same outline. This graph has a single kind of node (vertex node) that 
contains the coordinates of the tile it represents, which are used to position 
the node when the graph is visualized. Figure 4.1b shows an example of this 
graph. This graph can be used to visualize the rooms which compose the 
map. 


4.2.2 Reachability graphs 


Our tool can generate various kinds of reachability graphs that represent 
various ways in which it is possible to navigate the map. In these graphs a 
node represents a reachable position, whereas an edge indicates a viable path 
from a position to another. 


4.2.2.1 Tiles graph 


The tiles graph is generated starting from the text representation of a map 
and is obtained by associating a node to each empty tile and by connecting 
each node to its 8-neighbors. The horizontal and vertical edges have cost 1, 
whereas the diagonal ones have cost v2. This graph has a single kind of node 
(tile node) that contains the coordinates of the tile it represents, which are 
used to position the node when the graph is visualized. Figure 4.1c shows an 
example of this graph. This graph can be used to find the minimum distance 
that separates two cells, along with the shortest path that connects them. 


4.2.2.2 Rooms graph 


The rooms graph is generated starting from the All-Black representation of 
a map and is obtained by associating a node to each room and corridor and 
by connecting nodes which corresponding rooms or corridors overlap, using 
as weight the Euclidean distance of their central tile. This graph has a single 
kind of node (room node), used to represent both rooms and corridors that 
contains the coordinates of the closest and furthest vertex of the room from 
the origin. When visualized, each node is positioned on the coordinates of 
the central tile of the room it represents. Figure 4.1d shows an example of 
this graph. This graph can be used to analyze the topology of a map, in 
order to find loops, choke points, central areas and other kind of structures. 
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4.2.2.3 Rooms and game elements graph 


The rooms and game elements graph is an extension of the rooms graph, 
which also includes game elements as nodes, that are connected to the nodes 
corresponding to the rooms and corridors which contain them. In addition 
to the room node inherited form the rooms graph, this graph has a node 
to represent game elements (element node) that contains the coordinates of 
the game element, which are used to visualize the node, and the character 
associated to it. Figure 4.1e shows an example of this graph. 


4.2.3 Visibility graph 


The visibility graph is generated starting from the text representation of 
a map and is obtained by associating a node to each empty tile and by 
connecting each node to all the tiles that are visible from that node. For 
two tiles to be respectively visible, it must be possible to connect them with 
a line without crossing any filled tile. This graph has a single kind of node 
(visibility node) that contains the coordinates of the tile it represents, which 
are used to position the node when the graph is visualized, and its visibility, 
which is computed as the degree centrality, i.e. the number of edges incident 
to that node. A tile with high visibility allows to control a wide portion of a 
map, but at the same time an entity standing on it is easy to spot. To make 
this graph easier to read by the user, the tool associates a color to the nodes, 
which ranges from blue, for the ones with the minimum visibility, to red, for 
the ones with the maximum visibility. This can be seen in figure 4.1f. This 
graph can be used to analyze which areas of the map are more exposed and 
which ones are more repaired. 


4.2.4 Interesting metrics 


Considering the graphs, in particular the ones with room nodes, the following 
metrics defined by Graph Theory provide interesting information about the 
layout of a map: 


e Degree centrality: defined for a node, it is the number of edges that 
the node has. If the node represents a room, it measures how many 
entrance or exits the room has. 


e Closeness centrality: defined for a node, it measures its centrality in 
the graph, computed as the sum of the lengths of the shortest paths be- 
tween the node and all other nodes in the graph. If the node represents 
a room, it measures how central the room is. 
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(c) The tiles graph of the map. (d) The rooms graph of the map. 


(e) The rooms and game elements (£) The visibility graph of the map. 
graph of the map. 


Figure 4.1: A map and all the graphs that can be generated from it. 
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Betweenness centrality: defined for a node, it measures its centrality in 
the graph, computed as the number of shortest paths connecting the 
nodes that pass through the node. If the node represents a room, it 
measures how central the room is. 


Connectivity: defined for a graph, it is the minimum number of el- 
ements (nodes or edges) that need to be removed to disconnect the 
remaining nodes from each other. If the graph represents a map, it 
measures the existence of isolated areas. 


Eccentricity: defined for a node, it is the maximum distance from the 
node to all other nodes in the graph. If the node represents a room, it 
measured how isolated the room is. 


Diameter: defined for a graph, it is the maximum eccentricity of its 
nodes. If the graph represents a map, it measures the size of the map. 


Radius: defined for a graph, it is the minimum eccentricity of its nodes. 
If the graph represents a map, it measures how distanced the rooms 
are from each other. 


Periphery: defined for a graph, it is the set of nodes with eccentricity 
equal to the diameter. If the graph represents a map, it defines its 
peripheral areas. 


Center: defined for a graph, it is the set of nodes with eccentricity 
equal to the radius. If the graph represents a map, it defines its central 
areas. 


Density: defined for a graph, it ranges from 0 to 1, going from a graph 
without edges to a complete graph. If the graph represents a map, it 
measures how complex it is. 


4.3 Placement of game elements on the map 


We have defined multiple heuristics to populate a map with game elements 
using the metrics that can be extracted from a graph. These heuristic are a 
mathematical transposition of rules and patterns concerning game elements 
placement that we have extracted from the work of Tim Scháfer[18], who has 
performed an in depth analysis of multiplayer 1vs1 maps for Quake 22. 


Td Software, 1997 
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4.3.1 Rules for the placement of game elements 


The balance of a deathmatch game radically changes each time that a player 
is killed. If the game has more than two players, the player who won the fight 
does not gain any strategic advantage, since he still has the other players to 
face, whereas the defeated player is put at considerable disadvantage, because 
on death he loses all the weapons and ammunition that he has collected. In 
a lvs1 match, a kill has an even stronger influence, since the surviving player 
has more weapons and ammunition and gains the complete control of the 
map, that comes with the chance of scoring another easy kill, as soon as 
the other player respawns, or of searching for additional equipment. Schäfer 
refers to the surviving player as up-player and to the defeated one as down- 
player. 

To design a multiplayer map that is interesting and fun to play, it is im- 
portant to consider the up-player vs down-player dynamic both when defining 
the map layout and when positioning game elements. 

The spawn points, i.e. the locations where the down-player reappears, 
should be positioned in areas that are of low interest for the up-player and 
that are easy to leave. Obviously, central hubs and dead ends are a bad 
choice, whereas rooms with 2 or 3 exits are usually the best option. 

For what concerns the resources, they must be placed considering both 
the up-player vs down-player dynamic and the characteristics of the resource 
itself. It is important to place the right amount of resources on the map, 
because too many would eliminate the need for exploration, whereas too few 
would disadvantage the down player. It is also important not to place too 
many powerful items in the same area or in boring spots, since the risk to 
obtain them should always be proportional to the strategical advantage they 
allow to achieve. It is important to consider that a powerful resource is inter- 
esting for both players, so it often acts as a point of collision. The resources 
usually are of five kinds: health packs, armors, power-ups, ammunition and 
weapons. 

The health packs are placed in zones that are safe or not too dangerous. 
They have no use for the down-player, that respawns with full health, but 
they can be useful for the up-player, if he has been damaged during the fight, 
whereas they always come in handy during a fight or after that one of the 
contenders disengages. 

Armors, which supply a second health that is consumed before the main 
one, are usually placed in spots that are aimed both at the down-player and 
at the up-player: objects that provide a small quantity of armor should be 
easy to achieve, whereas the ones that provide full armor should be placed 
in dangerous areas. 
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Power-ups grant temporary advantages to the player who collects them, 
like invisibility or increased damage, and are placed in locations difficult to 
reach and contextual to their effect. 

The position of a weapon and of its ammunition depends on the weapon 
itself. We can divide the weapons in three categories: weak, medium and 
strong. Weak weapons are of a certain interest for the down-player, if he 
has not collected any other weapon yet, and of no interest for the up-player, 
so they are placed near spawn-points or in gaps where no other weapon is 
available, together with their ammunition. Medium weapons are of high 
interest for the down-player, since he needs to get one of them as soon as 
possible if he wants to face the up-player, so they are placed in areas that are 
easy to reach and the same goes for their ammunition. Finally, the strong 
weapons should be placed in areas that are strategically disadvantageous, like 
dead ends or vertically dominated areas, or difficult to reach. If a weapon is 
very contextual, i.e. it is useful in very few situations, it is usually placed in 
an area that allows to take advantage of its features, whereas a weapon that 
is strong in almost any situation is usually placed in an area where it cannot 
be used optimally (e.g. a rocket launcher in a small room). 


4.3.2 Placement process 


Starting from these considerations, we defined a process that allows to po- 
sition any kind of game element in two steps: the selection of a room and 
the selection of a tile inside the room. This process can be repeated as many 
time as needed, after having updated the graphs with the newly added game 
element. 


4.3.2.1 Room selection 
The selection of a room can be heuristic-based, uniform or random. 


Heuristic-based room selection This method selects rooms considering 
three suitability criteria: 


e Degree heuristic: defined by the function D(r), where r is a room node, 
it measures how much the degree centrality of the node matches the 
desired one. 


e Game element closeness heuristic: defined by the function H.(r), where 
r is a room node, it measures how much the closeness of the node to 
the already placed element nodes matches the desired one. 
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Given the rooms and game elements graph of a map (G,,) and the subset 
of room nodes (R C G,,), the room node which is selected is the one which 
maximizes the following weighted sum of functions: 


r* = argmax(wp x D(r) + wy, x He(r)) (4.1) 
reR 
The weights wp and wy, allow to define how much each one of the two 
heuristics influences the selection of a room. Both functions should be defined 
to output a value in the range [0, 1], in order to have the same influence for 
equal weight. 


Uniform room selection This method selects rooms that are uniformly 
distributed in the map. The first room is selected at random, then, given 
the rooms and corridors graph (G,,), the subset of room nodes (R C G;,,) 
and the subset of element nodes (S C G,,), the remaining rooms are selected 
with the following heuristic: 


r* = arg max(min(dsp(r, s))) (4.2) 
reR ses 


where dsp(n, m) denotes the length of the shortest path that connects the 
two nodes n and m, found using Dijkstra’s algorithm. 


Random room selection This method simply selects rooms at random. 


4.3.2.2 Tile selection 


The selection of a tile can be heuristic-based, uniform or random. 


Heuristic-based tile selection This method selects tiles considering three 
suitability criteria: 


e Visibility heuristic: defined by the function v(t), where t is a tile node, 
it measures how much the visibility of the corresponding tile matches 
the desired one. 


e Wall closeness heuristic: defined by the function H„(t), where t is a 
tile node, it measures how much the proximity of the corresponding 
tile to the walls matches the desired one. 


e Game element closeness heuristic: defined by the function H.(t), where 
t is a tile node, it measures how much the proximity of the node with 
already placed element nodes matches the desired one. 
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Given G, the visibility graph and T C G, the subset of tiles contained 
by the selected room, the tile which is selected is the one which maximizes 
the following weighted sum of functions: 


t = argmax(w, x v(t) + Wn, X hult) + wr, X he(t)) (4.3) 
teT 


The weights w,, wp, and wp, allow to define how much each one of the 
three heuristics influences the selection of a tile. All three functions should 
be defined to output a value in the range [0,1], in order to have the same 
influence for equal weight. 


Uniform tile selection This method selects tiles that are uniformly dis- 
tributed in the room. If no game element has been placed, the central tile is 
selected, otherwise it is picked out the one that maximizes the distance from 
the already positioned game elements but is not too close to the walls. 


Random tile selection This method simply selects tiles from the room 
at random. 


4.3.3 Heuristics for the placement of game elements 


Depending on how a game element needs to be placed inside the map, we 
have defined different heuristics to perform heuristic-based selection of rooms 
and tiles. 


4.3.3.1 Spawn points 


For spawn points, the heuristic-based approaches for rooms and tiles respec- 
tively select rooms that have a small number of connections, are not dead 
ends and are distant from each other and tiles that offer the best balance 
between low visibility and distance from the walls. In this way spawn points 
are placed in passageways that are sheltered and easy to leave. 


Room selection Considering equation 4.1 and given the rooms and game 
elements graph of the map (G,,), the subset of room nodes (R C G,,) and 
the subset of element nodes (S C G,,), the most suitable room for containing 
a spawn point is selected using the following heuristics: 


0 if deg(r) = 1 


D(r) = deg(r) — min„erdeg(r’) if deg(r) 41 (4.4) 


— maxwer deg(r’) — minyer deg(r”) 
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deg(r) 


Figure 4.2: How the degree heuris- 
tic defined for spawn points varies 
depending on the room node degree, 
with the degree ranging in [0, 15]. 


0 2 4 6 8 10 12 14 


deg(t) 


Figure 4.3: How the visibility heuris- 
tic defined for spawn points varies de- 
pending on the tile node degree, with 
the degree ranging in [0, 15]. 


1 ifinéS 
H.(r)= min dsp(r, n) (4.5) 
neGrr m if 
. diam(G,,) mn 


where deg(n) denotes the connectivity degree of the node n and diam(G) the 
diameter of the graph G. Equation 4.4 promotes rooms with few passages 
but that are not dead ends (see figure 4.2), whereas equation 4.5 promotes 
rooms that are distant from the already placed game elements. Both are 
normalized in the range [0, 1]. We empirically set the weighs to wp = 1 and 
WH. = 0.5. 


Tile selection Considering equation 4.2 and given the visibility graph of 
the map (G,), the subset of tile nodes that belong to the room (T € G,), 
the subset of tile nodes of the room which contain a game element (H CT) 
and the length of the diagonal of the room (ly), the most suitable tile for 
containing a spawn point is selected using the following heuristics: 


deg(t) — minyea, deg(t’) 


v(t) =1- (4.6) 


maxycq, deg(t’) — minyea, deg(t’) 


dwanlt, r*) 
maxyer dwau(t’, r*) 


h(t) = 
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0 if |H|=0 


he(t) = d(t,h 4.8 
| ) mMinneH È if || >0 l ) 
d 


where dwan(n,7) is the distance of the coordinates associated to the node n 
from the walls of the room r, computed as the sum of the minimum distances 
from the horizontal and vertical walls, and d(n,m) is the distance of the 
coordinates associated to the nodes n and m. Equation 4.6 promotes tiles 
with low visibility (see figure 4.3), equation 4.7 promotes tiles that are distant 
from the walls, whereas equation 4.8 promotes tiles that are distant from the 
already placed game elements inside the room. All three are normalized in 
the range [0,1]. We empirically set the weights as w, = 1, Wh, = 0.5 and 
Whe = 0.5. 


4.3.3.2 Health packs 


For heath packs, the heuristic-based approaches for rooms and tiles respec- 
tively select rooms that have a low-medium number of connections and are 
distant from each other and tiles that offer the best balance between medium 
visibility and distance from the walls. In this way the heath packs are placed 
in areas that are easy to reach and are not too exposed. 


Room selection Considering equation 4.1 and given the rooms and cor- 
ridors graph of the map (G,,), the subset of room nodes (R C G,,) and the 
subset of element nodes (S C G,,), the most suitable room for containing a 
health pack is selected using the following heuristic: 


faeg (r) == min,eR Tass (7°) 


— maxywer faeg(1') — minwer fieg(1°) 


D(r)=1 (4.9) 


with 


Faeg(r) = dint(deg(r), 0.3, 0.5) (4.10) 


Umin = V if vu < Vmin 
dint (v, Umins Unas) = 0 if Umin S v < Umax (4.11) 

V— Umar UU > Umar 
where din: is a function that measures the distance of a value from an interval 
of desired ones (see figure 4.4). Equation 4.5 is used for He. Equation 4.9 


promotes rooms with a low-medium number of passages. Both are normalized 
in the range [0,1]. We empirically set the weights as wp = 1 and wy, = 0.5. 
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Figure 4.4: The values assumed by Figure 4.5: How the visibility heuris- 

din with [0.3,0.5] set as interval of tic defined for health packs varies de- 

desired values. pending on the tile node degree, with 
the degree ranging in [0, 15]. 


Tile selection Considering equation 4.2 and given the visibility graph of 
the map G,, the subset of tile nodes that belong to the room (T € G,) 
and the subset of tile nodes of the room which contain a game element 
(H C T), the most suitable tile for containing a health pack is selected using 
the following heuristic: 


deg(t) — minyea, deg(t’) 


v(t) = 1 - |0.5 (4.12) 


 maxypeg, deg(t”) — minyeg, deg(t’) 


that promotes tiles with medium visibility (see figure 4.5). Equations 4.7 
and 4.8 are used for h,,(t) and h.(t), respectively. All three are normalized 
in the range [0, 1]. We empirically set the weighs to w, = 1, Wh, = 0.25 and 
Whe = 0.5. 


4.3.3.3 Ammunition 


For ammunition, the heuristic-based approaches for rooms and tiles respec- 
tively select rooms that have either a low-medium or a high number of con- 
nections and are distant from each other and tiles that offer the best balance 
between high visibility and distance from the walls. In this way ammunition 
is placed in areas that are either easy or difficult to reach and easy to spot. 


Room selection Considering equation 4.1 and given the rooms and cor- 
ridors graph of the map (G,,), the subset of room nodes (R C G,,) and the 
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subset of element nodes (S C G,,), the most suitable room for containing 
ammunition is selected using equations 4.5 and 4.9, with 


faeg(r) = dini(deg(r), 0.2, 0.4) (4.13) 
for obtaining rooms with a low-medium number of connections and 
Fieg(r) = dint(deg(r), 0.8, 0.9) (4.14) 


for obtaining rooms with a high number of connections. We empirically set 
the weighs to wp = 1 and wy, = 0.25. 


Tile selection Considering equation 4.2 and given the visibility graph 
(G,), the subset of tile nodes that belong to the room (T C G,) and the 
subset of tile nodes of the room which contain a game element (H C T), the 
most suitable tile for containing ammunition is selected using the following 
heuristic: 


deg(t) — minyer deg(t”) 


v(t) = (4.15) 


maxyer deg(t’) — minyer deg(t’) 


that promotes tiles with high visibility. Equations 4.7 and 4.8 are used for 
hw(t) and he(t), respectively. All three are normalized in the range [0, 1]. We 
empirically set the weights as w, = 1, wp,, = 0.25 and wa, = 0.5. 


4.3.4 Weapon placement 


For what concerns the weapons provided by the framework we have not 
defined any specific heuristic, but, beside the assault rifle which is always 
available to the player, they could be placed as follows: 


e Shotgun: since it is a medium damage weapon it could be positioned 
in a room that has a medium number of connections and is relatively 
close to a spawn point. 


e Rocket launcher: since it is a high damage weapon it could be posi- 
tioned in a room that has a high number of connections, creating an 
interesting collision point, or in a dead end, where its utility is limited. 


e Sniper rifle: since it is a high damage weapon it could be positioned in 
a room that has a high number of connections, creating an interesting 
collision point. 
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4.4 Summary 


In this chapter we analyzed the approach that we have defined to perform 
map analysis and placement of game elements using Graph Theory. After 
an overview of the graphs and metrics that allow to highlight interesting 
information about a map, we listed the rules and patterns commonly used 
to position game elements in deathmatch maps and we described how we 
converted them into heuristics. 
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Chapter 5 


A case study: spawn points 
placement 


In this chapter we discuss a case study we designed to test the effectiveness 
of our framework. We performed an experiment with real users to validate 
the placement heuristics for spawn points and, at the same time, to test the 
data-collection capabilities of our framework, that was used to setup and 
manage the experiment. 


5.1 Goals 


We designed this experiment to analyze how our methods for the placement 
of spawn points influence the up-player vs down-player dynamic and to prove 
their effectiveness. We tried to recreate the situation where the up-player, 
once killed his opponent, tries to find him as soon as possible, just after his 
respawn, to score another easy kill. As we have seen, a well-designed map 
should slow down this operation by having its spawn points in areas that 
are not central, are easy to leave and covered. In this experiment we com- 
pared two approaches: the uniform one, that selects rooms with the uniform 
method (see subsubsection 4.3.2.1) and tiles with the heuristic defined for 
spawn points, and the heuristic one, that selects both rooms and tiles with 
the heuristics defined for spawn points (see subsubsection 4.3.3.1) and should 
allow to obtain a placement of spawn point coherent with the one described 
above. These two approaches use the same method to select tiles in order 
to focus on the effects of room selection, since the ones of tile selection are 
rather obvious (an object on a tile with a low visibility is difficult to find). 
To highlight this gameplay dynamic, we designed a game mode where the 
user, which represents the up-player, must find and destroy a static target, 
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which represents the down-player, as many times as possible before times 
runs out. Each time that the user destroys a target, it respawns at a random 
spawn point. The user cannot die and has infinite ammunition, so he does 
not have to look for resources. 


5.2 Experimental design 


For this experiment, we setup the Experiment Manager to propose in each 
play session a quick tutorial, two matches and a survey. The experiment 
was composed by three studies, corresponding to three different maps, each 
one composed by two cases, one corresponding to the map populated with 
the heuristic approach and one corresponding to a pool of five versions of 
the map populated with the uniform approach!. In a play session, the user 
played the same map twice, once with the heuristic distribution and once 
with the uniform distribution, in a random order and with the map flipped 
in one of the two matches. We used the survey to profile each user according 
to their skill and familiarity with video games and FPS and to get a feedback 
about the match in which they found it harder to locate the targets. The 
experiment was deployed online and played by the users via browser on their 
own computers. 

As game mode, we used Target Hunt, with the game duration set to three 
minutes, the list of spawnable entities composed of just one target and an 
assault rifle with infinite ammunition as the only weapon available to the 
player. The maps were stored as text files and displayed with the Prefab 
Assembler. 

For each match, a complete game log was saved, along with the following 
performance metrics, saved in a separate log: 


e TargetLogs: this field contains a list of all the targets that the user 
managed to destroy. Each entry contains a timestamp, the coordinates 
of the destroyed target, the coordinates of the user, the distance covered 
by the user and the time passed during the lifespan of the target. 


e Shots: the total number of projectiles shot by the user. 
e Hits: the number of projectiles that hit a target. 
e Accuracy: the percentage of projectiles that hit a target. 


e Kills: the total number of targets destroyed by the user. 


When selecting rooms with the uniform method the first one is chosen at random. This 
allows to obtain multiple versions of the same map. 
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e Distance: the total distance covered by the user during the match, con- 
sidering his complete trajectory and cells of unitary width as reference 
unit. 


e AvgKillTime: the average time needed for the user to find a target, 
computed as the duration of the match divided by the number of kills. 


e AvgKillDistance: the average distance covered by the user to find a 
target, computed as Distance divided by the number of kills. 


The performance of the player is measured by AvgKillTime and AvgKillDis- 
tance, that are also indicators of how difficult it is to find targets in the map. 
The answers to the survey were saved as well. 

The three maps that we have selected for this experiment have very dif- 
ferent layouts: 


e Arena: this map presents a wide arena, two sides of which are adjacent 
to parallel corridors with many openings. As the visibility heatmap 
in figure 5.1a shows, the central arena allows to control most of the 
map, whereas the corridors offer some repair and perfect spots to place 
spawn points. Figure 5.1b shows the spawn points positioned using the 
heuristic approach, whereas figure 5.1c shows one of the five configura- 
tion produced with the uniform approach. 


e Corridors: this map presents many small rooms connected by long 
corridors. As it can be seen in figure 5.2a, there is no area that allows 
to control the others and the only points with high visibility are the 
ones where corridors intersect. Figure 5.2b shows the spawn points 
positioned using the heuristic approach, whereas figure 5.2c shows one 
of the five configuration produced using the uniform approach. 


e Intense: compared to the previous two, this map presents an interme- 
diate layout, since it has both open areas and small rooms connected 
by corridors. As it can be seen in figure 5.3a, this reflects also on 
the visibility, that is high in the open areas and low in the remaining 
sections of the map. Figure 5.3b shows the spawn points positioned 
using the heuristic approach, whereas figure 5.3c shows one of the five 
configuration produced using the uniform approach. 


As we have said, the heuristic and the uniform approaches select rooms 
with two different criteria, but they employ the same logic when selecting 
tiles. This means that the two heuristics select tiles which have similar 
visibility conditions, so the player’s performance depends exclusively on how 
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(a) Heatmap showing Spawn points (in (c) Spawn points (in red) 
the visibility of the level. De placed using the es using the si 
heuristic approach. approach. 


Figure 5.1: “Arena” map used in the experiment. 


(a) Heatmap showing Spawn points (in (c) Spawn points (in red) 
the visibility of the level. i placed using the e using the dn 
heuristic approach. approach. 


Figure 5.2: “Corridors” map used in the experiment. 


(a) Heatmap showing (b) Spawn points (in (c) Spawn points (in red) 
the visibility of the level. red) placed using the placed using the uniform 
heuristic approach. approach. 


Figure 5.3: “Intense” map used in the experiment. 


62 


5.3. Results 


Total Arena | Corridors| Intense 
Number of samples 27 10 9 8 
Heuristic| 104.04 114.89 101.00 94.88 
(Shots) — 
Uniform | 117.44 131.33 100.25 119.00 
. Heuristic| 42.68 48.44 43.50 35.38 
(Hits) — 
Uniform 50.12 54.22 44.50 51.13 
Heuristic 0.45 0.43 0.51 0.40 
(Accuracy) — 
Uniform 0.48 0.45 0.52 0.48 
; Heuristic| 10.06 10.75 10.44 8.75 
(Kills) — 
Uniform 11.88 12.27 10.67 12.75 
: Heuristic| 675.22 633.56 675.43 716.68 
(Distance) — 
Uniform | 680.79 649.62 688.34 704.42 
u(AvgKillTime) pause 20.24 21.09 18.25 21.40 
Uniform 16.06 15.50 17.46 15.18 
lidia Senne 73.34 64.21 70.90 84.90 
Uniform 60.70 55.24 68.13 58.72 
Mo(Difficulty) iv ARUEGHO Keurig uk uniform au 
Percived | heuristic | heuristic | equal | heuristic 


Table 5.1: The information retrieved from the dataset. u denotes the mean 
value and Mo denotes the modal value. 


the rooms have been selected. This is observable in figures 5.1, 5.2 and 5.3: 
when the uniform approach happens to select a room that has been selected 
also by the heuristic one, the spawn point is placed exactly on the same tile. 


5.3 Results 


The data collected with this experiment consisted of 27 samples. As table 5.1 
shows, of these 27 samples, 10 are pairs of matches played in map “Arena”, 
9 are pairs of matches played in map “Corridors” and 8 are pairs of matches 
played in map “Intense”. The table also shows the values of the metrics that 
we have defined classified by map and placement method. 

As we have seen, the performance of the player is measured with AvgKill- 
Time and AvgKillDistance and by computing their mean values we observed 
that the users performed better in the matches associated to the uniform 
approach with respect to the ones associated to heuristic approach. For 
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the former the mean value of AvgKillTime is 16.06 seconds and the one 
of AvgKillDistance is 60.7 cells, whereas for the latter the mean value of 
AvgKillTime is 20.24 seconds and the one of AvgKillDistance is 73.34 cells. 
The respective increase of 26% and 21% on the average time and distance 
needed to find a target confirms that spawn points placed with the heuristic 
approach are more difficult to find than the ones placed with the uniform 
approach. 

To test the statistical significance of this result, we performed the Wilcoron 
statistical test? by Pratt, using as matched samples the values assumed by 
the metric at issue when using heuristic placement and when using uniform 
placement. Both AvgKillTime and AvgKillDistance passed the test, the for- 
mer with a = 0.00203 < 0.005, one-tiled, and the latter with a = 0.01243 < 
0.05, one-tiled. 

The effect of the two approaches on the metrics can also be analyzed by 
plotting their values, assigning to the horizontal axis the value of the metric 
in maps with heuristic placement and to the vertical axis the value of the 
metric in maps with uniform placement. Each point of such graph represents 
the outcome of a test whose coordinates are the values of the metric in the 
two matches. By tracing the bisector, it is easy to see for which of the two 
approaches a metric is higher. If the points are scattered under the bisector it 
means that the metric tends to be higher for the heuristic approach, whereas 
if they are scattered above the bisector it means that the metric tends to 
be higher for the uniform approach. Figure 5.4 shows such graphic for each 
metric: 


e Kills: as figure 5.4a shows, the number of kills tends to be higher 
with the uniform placement (11.88 > 10.06, considering the mean val- 
ues). This result is rather obvious, since, as we have seen analyzing 
AvgKillTime and AvgKillDistance, targets are more difficult to find 
with the heuristic placement. The Wilcoxon test, which is passed with 
a = 0.00347 < 0.005, one-tiled, confirms this outcome. 


e Distance: as figure 5.4b shows, the total distance covered by users is 
not influenced by the employed placement method (680.79 = 675.22, 
considering the mean values). This is due to the fact that users are 
constantly moving and the agility with which they navigate the map 


?The Wilcoron signed-rank test is a non-parametric statistical hypothesis test used to 
compare two matched samples to assess whether their population mean ranks differ. 
3With respect to the standard Wilcoxon test, the one by Pratt considers also the obser- 
vations for which the difference of the elements in the pair is zero. We opted for this 
approach since some samples happen to have metrics with the same value for the two 
placements. 
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Figure 5.4: Experiment outcomes by metrics. The outcome associated to 
the heuristic approach is on the horizontal axis, the one associated to the 
uniform approach is on the vertical axis. 
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depends exclusively on their familiarity with FPS games and on the 
layout of the map. The Wilcoxon test, which is not passed with a = 
0.294 > 0.05, one-tiled, confirms this outcome. 


e Shots: as figure 5.4c shows, the number of shots tends to be higher 
with the uniform placement (117.44 > 104.04, considering the mean 
values). This result is coherent with what we have observed for Kills, 
to which Shots is expected to be directly proportional. The Wilcoxon 
test, which is passed with a = 0.0336 < 0.05, one-tiled, confirms this 
outcome. 


e Accuracy: as figure 5.4d shows, the accuracy is not significantly in- 
fluenced by the used placement method (45% = 48%, considering the 
mean values). This is due to the fact that the accuracy depends almost 
exclusively on the aiming skills of the user. The Wilcoxon test, which 
is not passed with a = 0.294 > 0.05, one-tiled, confirms this outcome. 


We also observed that the effects of the placement were considerably 
different depending on the layout of the map. With the heuristic placement, 
map “Arena” had a mean number of kills of 10.75, map “Corridors” of 10.44 
and map “Intense” of 8.75. We expected the one of “Arena” to be the highest, 
because of its central area that dominates the rest of the map, but we did not 
expect the ones of “Corridors” to be almost as high, since its structure is more 
difficult to navigate. Moreover, we expected an intermediate number of kills 
in “Intense”, since it merges the features of the two other maps, but it proved 
to be the map where targets were harder to find. This could be explained by 
the fact that “Corridors”, even if more complex than “Arena”, has a rather 
regular structure and its long corridors allow to easily spot a target. Instead, 
for what concerns “Intense”, its structure is rather complex and difficult to 
navigate and since the central open area does not allow to control all of the 
map the tactical advantage it provides is not so strong. With the uniform 
placement the mean number of kills of “Arena” increased to 11.88, the one 
of “Corridors” remained almost the same (10.67) and the one of “Intense” 
increased dramatically to 12.75. The reasons for such different reactions lies 
in the layout of each map. The central area of “Arena” allows to control all 
of the surroundings, so the placement of spawn points in areas that are less 
visible has a relevant effect. “Corridors”, instead, has a regular structure 
and the number of intersections between its corridors is almost always the 
same, so it is not relevant where spawn points are placed, since all the rooms 
have the same features. Finally, the tangled structure of “Intense” offers to 
the heuristic approach a lot of interesting spots where to place spawn points 
and the presence of an area that allows a partial control of the map makes 
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this choice even more meaningful. This shows that the effects of the heuristic 
approach are more pronounced in maps which layout is not uniform. 

The position of spawn points also influenced the way in which users moved 
across the maps. Figure 5.5 shows, for each map and for each placement 
method, the heat maps of the sections that where crossed more frequently 
by the users. It is possible to notice that users, once understood the topology 
of the map, started to follow well defined farming routes*. These routes tend 
to be circular and to skirt the perimeter of the maps, with deviations that 
are influenced by the position of spawn points. The overall circularity is 
remarked by the heat maps associated to the uniform positioning, that being 
obtained by a set of five different uniform placements’, represent an average 
route with respect to the possible position of spawn points. 

It is also interesting to notice how the difficulty in finding the targets was 
perceived by the users. As it can be seen in figure 5.6, in the survey the ma- 
jority of the users classified as more difficult the match where they performed 
worst, but some of them answered with the one where they performed better. 

Finally, the intuition of flipping one of the two maps was correct, since 
many users believed to have played two completely different maps. 


5.4 Summary 


In this chapter we analyzed the experiment that we setup and its results, that 
proved the effectiveness of our heuristics and of our framework. We observed 
that the heuristic placement makes the targets harder to find, whereas the to- 
tal distance covered by the user and the shooting accuracy are not influenced 
by the employed placement method. We also discovered that our heuristics 
work better with maps that do not have an uniform topology and we ob- 
served that users tend to define and follow specific routes when performing 
a research. 


In video games, farming routes are regular closed paths defined to maximize the collection 
of certain resources in a specific map. 
"The uniform study has five cases, whereas the heuristic study has just one. 
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a) Map “Arena” with heuristic b) Map “Arena” with uniform 
en Li 
(c) Map “Corridors” with d) Map “Corridors” with uni- 
heuristic placement. +. placement. 

e) Map “Intense” with heuris- f) Map “Intense” with uniform 
2 placement. an 


Figure 5.5: Heat maps of the player positions for the three maps used in the 
experiment. The red circles represent spawn points. 
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Figure 5.6: Comparison between the effective and the perceived difficulty. 
Each square contains the number of samples where the user performed worst 
in the match with placement Effective and evaluated as more difficult the 
match with placement Percived. The match where a user performed worst is 
the one with the highest AvgKillTime. 
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Chapter 6 


Conclusions 


The purpose of this thesis was to create a framework to perform research in 
Procedural Content Generation for First Person Shooters and to attempt a 
new approach to level design analysis and game element placement. 

Past works have employed open source games, like Cube 2, that allow to 
perform validation via artificial agents but present many limitations when it 
is needed to collect information from real users. There was therefore the need 
of a way to collect data online, in an easy and quick way, and we answered 
to it by designing a framework to deploy browser playable experiments, that 
once defined collect data automatically. Being aimed at research, we wanted 
our framework to be as versatile as possible, so we opted for a modular and 
parametric design that is easy to customize and we included many generation 
algorithms and map representation formats, both single-level and multi-level, 
that have been used in previous works. We included the All Black format, 
defined by Cardamone et al.[12], that is a standard in the literature, but we 
extended it to be more complete and flexible, introducing variable genome 
size, game elements codification and multi-level support. 

We explored how Graph Theory can be applied to level design, with re- 
gard to both map analysis and placement of game elements. For the former, 
we defined various graphs that can be generated from the All-Black represen- 
tation of a map, each one highligthing different features such as the visibility 
or the reachability of tiles and rooms, and we selected some indicators from 
Graph Theory that allow to obtain topological information about the map 
at issue. For the latter, we defined an approach that uses heuristics to place 
game elements, taking into account their specific features and the indicators 
that we have selected. To define these heuristic, we analyzed how game ele- 
ments influence the up-player vs down-player dynamic and how they should 
be positioned to create an engaging and balanced gameplay. This new ap- 
proach to the subject proved to be very interesting, since it allows to analyze 
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level design from a new perspective and to easily define topological rules. 

Finally, we tested our framework by performing an experiment to analyze 
how the placement of spawn points influences the up-player vs down-player 
dynamic. With this experiment we were able to validate the placement 
heuristics that we have defined and we managed to observe how the map 
layout influences the disposition of game elements. In this way, we proved 
our graph-based approach to be useful both for map analysis and for the 
contextual positioning of game elements. 


6.1 Known issues and possible criticism 


The main issue with the framework is that it does not have neither artificial 
agents nor the support for online multiplayer and this limits its possible 
applications. 

For what concerns graph analysis, the rules that we have defined for plac- 
ing game elements could be criticized for a lack of a strong theoretical basis, 
since as we have seen there is still no common ground for what concerns level 
design. Moreover, we assigned the weights used in the placement heuristics 
empirically, making various attempts and choosing the weights that produced 
the disposition of game elements most coherent with the rules we defined. 
Despite this, the experiment proved both the rules and the weight assignment 
to be effective. 


6.2 Future developments 


Two major features that should be implemented in the framework are an 
artificial intelligence for agents and the support for online multiplayer, since 
they would allow to significantly increase the possible applications of our 
work. Moreover, to make the framework more complete and allow to directly 
generate well designed maps, it would be a great improvement to implement 
the map analysis and the game element placement directly in the framework, 
instead of performing them using an external tool. 

In subsection 4.2.4 we listed many metrics that can give interesting in- 
formation about the layout of a map, but we have used only some of them 
to define the placement heuristics. An interesting development would be to 
include more of them, in particular the ones that allow to define areas of the 
map, like Periphery and Center. As we have highlighted, weapons require 
a specific treatment when positioned, since their overall damage, strengths 
and weakness should influence their place in the map, and such metrics can 
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be employed to define the areas that better suit each weapon. These new 
heuristics, as well as the already defined ones, would benefit of an exper- 
imental analysis similar to the one used to validate the heuristics for the 
placement of spawn points. Another improvement would be the extension of 
the analysis performed via graph to multi-level maps. Moreover, as we have 
already highlighted in the thesis, the graphs we have defined could be used 
for the individuation and analysis of design patterns. 

Finally, it would be interesting to design an evolutionary process that 
generates maps and places resources using a fitness function addressed to 
the up-player vs down-player dynamic. 
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